Today's network links carry vast amounts of information. High bandwidth applications supported by these network links include, for example, streaming video, streaming audio, and large aggregations of voice traffic. In the future, network bandwidth demands will increase. Certain applications, such as streaming audio and streaming video, can generate a large amount of network traffic due to sending such a transmission to multiple subscribers. In order to help decrease network traffic load due to such applications, multicast extensions to network protocols have been developed.
Multicast protocols enable multicast transmission (i.e., one-to-many connections) by replicating a multicast network frame close to the destination of that frame, obviating the need for multiple unicast connections for the same purpose, thereby saving network bandwidth and improving throughput. Upon receiving a multicast frame, a network node can examine a multicast group destination address (GDA) of the frame and determine whether subscribers to the multicast frame are coupled, directly or indirectly, to the network node. The network node can then replicate the multicast frame as needed and transmit the multicast frame to any connected subscribing nodes.
FIG. 1 is a simplified block diagram of a network switch 100. The switch provides ports 110(1)-(N), wherein a network frame arriving at any port can be directed to any other port connected to the switch as determined by an examination of the frame's destination address. Connected to each port are network nodes 120(1,1)-(N,M). In a typical network environment, each network node 120(1,1)-(N,M) has a unique media access control (MAC) address. Switch 100 can learn the MAC addresses of network nodes 120(1,1)-(N,M) as those nodes transmit frames to each other via the switch. Each frame transmitted by a network node contains a source MAC address that switch 100 can read and associate with the coupled port. Such node-port information is stored in an address table. Such a table has been called an L2 address table (referring to Level 2 of the Open System Interconnection (OSI) networking framework for implementing protocols, which is also called the data link layer) or an MAC address table.
Within the OSI network model, a network node, or applications on a network node, can have a different representation of its network address at each level of the model. As described, switch 100 operates at Level 2 (L2). These L2, or MAC addresses, of a network node are unique to each network interface on a network and are typically hardware encoded in the network interface. MAC addresses are 48 bits in length, containing a 24-bit vendor code followed by a 24-bit hardware address. A network node can also have an OSI Level 3 address, which can be an address such as Internet protocol (IP) addresses. IP addresses are software encoded and can be supplied by a network administrator or dynamically determined within the environment that the network node resides. In version 4 of the Internet protocol (IPv4), L3 addresses are 32 bits in length, while in Internet protocol version 6 (IPv6), L3 addresses are 128 bits in length. When transmitting over a network, an OSI Level 3 packet is encapsulated within an OSI Level 2 frame, therefore such frames contain both L2 and L3 source and destination addresses.
FIG. 2 illustrates an L2 address table showing node-port associations of switch 100. Each entry in the table has an associated index 210. The number of entries in the table can be equal to the number of nodes connected to switch 100 (e.g., P). Each entry in the table includes a MAC address 220 that corresponds to a source MAC address found in frames transmitted by each node (e.g., SMAC (120(1,1)) is the source MAC address for node 120(1,1) in FIG. 1). Each L2 address table entry also includes a port 230 corresponding to the node, wherein the node-port association is made by switch 100 when it receives a frame from the network node. Information linking a node address with a particular port is related to the hardware of the node (e.g., a network interface) and is typically static in an L2 address table, unless a node is physically moved from one port to another port on the switch. An additional field of data that can optionally be included in an L2 address table is a broadcast domain identifier 235. Such a broadcast domain identifier can be that of a virtual LAN (VLAN). VLAN associations of ports can be configured in software by a network administrator.
An L2 address table cannot automatically be populated with multicast destinations as is done with node-port designations. This is because a multicast GDA cannot be a source MAC address. Typically, a portion of an L3 multicast GDA is included in an L2 address table through the use of software protocols such as the Internet Group Management protocol (IGMP). When a network node wishes to subscribe to a multicast transmission, a special IGMP frame is transmitted as a multicast “join” request. An IGMP-enabled switch can have “snooping” software to allow the switch to read the IGMP frame and build a corresponding entry in the L2 address table. Such an entry can relate a form of the multicast GDA (an L3 address) with ports that are connected to subscribing nodes. An IGMP frame contains an L3 GDA along with other information pertinent to the operation requested in the IGMP frame. Such an L3 address requires manipulation to be included in an L2 address table.
FIG. 3 illustrates a manipulation of IPv4 and IPv6 multicast group destination addresses into a form acceptable for inclusion into entries of an L2 address table. An IPv4 GDA is 32 bits in length an falls in the range of addresses 224.0.0.0-239.255.255.255. Such an IP address is illustrated at 301 in FIG. 3. As stated above, an L2 address is limited to 48 bits, which is split into two 24-bit segments. The first three octets (the first 24 bits) of an L2 MAC multicast address are set to 01:00:5e (325). To create an L2 MAC multicast address for the L2 address table corresponding to an L3 GDA, the last 23 bits of the L3 GDA are inserted into the last 23 bits of the MAC address 320. Five of the nine bits are significant, since the first four bits of any IPv4 multicast address are always 1110. Similarly, an IPv6 address is 128 bits in length, and an L3 IPv6 GDA (330) is converted to an L2 MAC address (340).
FIG. 4A illustrates an L2 address table including MAC multicast destination addresses. As with FIG. 2, the table contains an initial set of P entries, each containing index 410, address 420 and port 430. The first set of unicast addresses 440 is received into the table as discussed above. A set of multicast destination addresses 450 is illustrated as additional entries (P+1) and (P+2). As illustrated, a generic MAC multicast destination address 460 includes the initial octets 01:00:5e, followed by a subsequent set of three octets into which bits from the IPv4 GDA are inserted. Each multicast entry is associated with a group of one or more ports (470) coupled to subscribing network nodes.
Typically, when an L2 network device such as switch 100 receives a multicast frame, the L2 network device performs a lookup in the L2 address table to determine if there is a corresponding entry for the L2 multicast destination address of the multicast frame. If there is a corresponding entry within the L2 address table, then the L2 network device replicates the multicast frame, as needed, and transmits the replicated multicast frame to all the ports associated with the multicast destination address in the L2 address table entry. Should an L2 network device receive a multicast frame for which there is no corresponding entry in the L2 address table, also known as an out-of-profile multicast frame, then a typical response is to flood the broadcast domain upon which the multicast frame was received with replicated frames. That is, each port associated with the broadcast domain will receive a transmission of the out-of-profile multicast frame. Transmission of an out-of-profile multicast frame to all ports in a broadcast domain is called multicast flooding.
An out-of-profile multicast frame can be received for a variety of reasons. For example, the L2 network device may not have any multicast forwarding states in the L2 address table, or the L2 network device may not support protocols for multicast forwarding optimization such as IGMP snooping, PIM snooping or the L2 network device may have run out of space in the L2 address table so that new multicast destination addresses cannot be created in the table. Regardless of the reason for a multicast flooding, such flooding can be an undesirable condition.
Among the reasons that multicast flooding can be considered undesirable are that network resources such as bandwidth and processing are consumed by the replication and transmission of an out-of-profile multicast frame on all ports belonging to the broadcast domain. Further, processor resources in downstream L2 and L3 network devices can be consumed by having to examine and drop unnecessary frames. Prior art solutions to avoiding multicast flooding include dropping frames directed to an out-of-profile multicast destination address or rate limiting the transmission of such frames.
Dropping an out-of-profile multicast frame can be undesirable because not all out-of-profile multicast frames are necessarily unwanted. For example, as suggested above, the L2 network device could have run out of space in the L2 address table and therefore could not create a new entry for a subscriber node. Therefore, dropping the out-of-profile multicast frame can result in a subscriber node not receiving the frame. Similarly, if the L2 network device does not contain multicast states in the L2 address table or does not support protocols for adding multicast addresses in an optimized fashion, subscriber network nodes will not receive a desired transmission.
Rate limiting the flooding of out-of-profile multicast frames is a median solution between dropping all such packets and flooding all such packets. The L2 network device can set an outgoing packet rate for out-of-profile multicast flooding. Therefore some of the frames of an out-of-profile multicast transmission will get transmitted to all ports in the broadcast domain and some will be dropped. Again this can be an undesirable solution for those nodes that may want to receive that multicast transmission but have no means for getting that subscriber information into the L2 address table.
What is therefore desired, is a means to provide out-of-profile multicast frames only to network nodes for which it is desirable to send such traffic. In other words, it is desirable to constrain multicast flooding to a multicast flood domain that includes either a set of statically-selected nodes or dynamically determined nodes.